docs(verification): profile floors are specification choices, not regulatory derivations - #310
Open
ioanavalea wants to merge 1 commit into
Open
docs(verification): profile floors are specification choices, not regulatory derivations#310ioanavalea wants to merge 1 commit into
ioanavalea wants to merge 1 commit into
Conversation
… correct the Annex IV attribution Annex IV is the technical documentation schedule referred to in Article 11(1) rather than a classification annex, so "Annex IV high-risk" names no category a reader can look up. High-risk classification runs through Article 6 with Annexes I and III. No provision of the Regulation requires a verification depth, so the floor is stated as a choice this specification makes rather than a derivation from any regime. The regulatory detail moves into an informative section recording what each instrument requires and nothing beyond it. Documentation only. No normative delta, no schema change, no conformance test IDs. Signed-off-by: Ioana Valea <ioana.valea02@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
docs/verification.mdpresents thetransitiveprofile floor as following from "EU AI Act Annex IV high-risk". This corrects that attribution, keeps every profile and every floor exactly as it stands, and adds an informative section recording what the cited instruments actually require.The line being corrected:
Type of change
The added subsection is informative and sits in
docs/rather than in the specification, so it carries no normative effect and no conformance test IDs.Spec section
None. The change is confined to
docs/verification.md. Section 3.3.1 ofspec/trace-v0.2.md, which this document is the implementation guide to, is unchanged, and no schema file is touched.Why
Two separate problems sit in the same phrase.
Annex IV is the technical documentation schedule whose elements Article 11(1) requires the technical documentation to contain at a minimum. It is not a classification annex, so "Annex IV high-risk" names no category a reader can look up, since high-risk classification runs through Article 6 with Annexes I and III. The row now reads "EU AI Act Article 6 high-risk".
Separately, no provision of the Regulation requires a verification depth, so a floor cannot be derived from it. The floor is still the right requirement for that profile, and it is a requirement this specification makes rather than one the Regulation imposes. The lead-in now says so for every row.
No other instrument is put in Annex IV's place. A floor that rests on a citation is only as stable as the reading of that citation, and the security argument already in this document carries the floor without one. The regulatory material therefore moves into an informative section that records what each instrument requires and stops there, which also keeps the table clear of anything a reader could take as a compliance claim. @safal207's refinement is carried in that section: the software bill of materials obligation in the CRA is a component inventory, and an inventory of top-level dependencies does not by itself establish
builderortransitiveverification, which are claims about provenance rather than about composition.FIPS and HIPAA are unchanged and are not spoken to here, as in my comment on #66.
Not changed, deliberately
The depth vocabulary is untouched. #66 gives the same supply-chain ladder two names,
surface | builder_chain | dependency_chainforverification.depthandsurface | builder | transitiveforbuild_provenance.provenance_depth, and reconciling the two was asked for on that thread.docs/verification.mduses the short names throughout, so this PR uses them too. Which vocabulary survives is a maintainer decision worth settling before v1.0, and this PR does not make it.No new conformance claim and no legal-compliance claim are introduced, and the informative section states explicitly that verification at any depth is not evidence of compliance with either instrument.
Context
The profile-floor correction was directed on #66 to be a separate docs-only contribution with source verification and no new conformance or legal-compliance claim: #66 (comment). #66 has since been closed via #306, whose description states that it does not close #66, so this is filed as the separate contribution that was asked for rather than as a change to that issue's scope.
Checklist
git commit -s)CHANGELOG.mdupdated (for any normative change): not applicable, no normative changeAI assistance
Drafting and source verification were AI-assisted. Article 6, Article 11(1), Article 15(5), Article 25(4), Article 111(2), Article 113 and Annex IV were read against Regulation (EU) 2024/1689 as amended; Article 1 points (10) and (12) and the Article 113 replacement against Regulation (EU) 2026/1744; and Annex I Part II point 1 and Article 71 against Regulation (EU) 2024/2847, before being cited.